10: Notices queue - #10

Three defects, each of which loses the one warning a site owner gets that
their plugin was deactivated.

Storage was a transient. Verified in core: set_transient() short-circuits
to wp_cache_set() and never touches the database when an external object
cache is present, so on a Redis or Memcached site the queue lived only in
the cache -- where wp_cache_flush(), which deploy scripts and every purge
button call, destroys it. The merge notice is raised once and never
re-queued. It is an option now.

The queue was per-site while the deactivation is network-wide. The resolver
passes $network_wide to deactivate_plugins(), removing the plugin from every
site, but the explanation landed in whichever site's options table served
the request. On a fifty-site network the superadmin would never find it.
Multisite uses network options now.

render() consumes the queue and had no capability check, and it is wired to
a hook that fires for anyone who can reach wp-admin. A subscriber loading
profile.php silently swallowed the notice, and nothing re-queues it. It
checks activate_plugins first, which on multisite correctly resolves to
superadmins.

Also drop non-string entries instead of printing them, expose
option_name() so a host can render the same queue without replacing the
implementation, and cover the corrupted-queue, capability, cache-flush and
missing-prefix paths.